HPAVC

home *** CD-ROM | disk | FTP | other *** search

/ HPAVC / HPAVC CD-ROM.iso / pc / CIS_GAME.ARJ / QFOFX1.THD < prev next >

Wrap

Text File | 1993-07-01 | 53.7 KB | 1,117 lines

_________________________ Subj: Flights of Fantasy _________________________ Fm: Mitchell Waite 75146,3515 # 332701 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 13-Apr-93 11:19:14 Today fractal landscapes in Rescue on Fractalus are pretty poor when compared to Comanche as far as realism is concerned. I know that guy that wrote the ROF fractals. It would be fun to add a chapter in the sequel to FOF that shows how to do 3D landscape generation following the Comanche approach, that is prestoring height info and finding a way to reconstruct the original terrain. But before that I would like to see FOF take on some simple polygon mountains and terrain like the kind used in Falcon 3. Then I'd like to see some bit mapped mountains. Speaking of wish lists, here is mine: 1. Outside the cockpit views. 2. More items on the ground and an editor for building your own gound objects. 3. Enemy planes, wingman, and engagement. 4. More weapons and a weapons editor. Anybody got another other ideas/requests/wishes? Mitch ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 332757 To: Mitchell Waite 75146,3515 (X) Date: 13-Apr-93 12:35:46 RESCUE ON FRACTALUS was awfully impressive in its day. Nobody'd ever done anything like that before. Of course, that was the better part of a decade ago and it was written on an 8-bit machine, so it looks kinda crude now. But it demonstrated basic principles that are still being explored by programmers in the 1990s! There's no question that the FOF sequel should include COMANCHE-style landscape representation, though I suspect it will require more than one chapter. And, yes, there should be more done with polygon mountains. This won't require too much new technology over the first FOF, just more work on the scenery database. What's really needed is the program I never quite got working in FOF, to generate complex mountain shapes. I've got some new ideas about that one, so maybe this time I'll get it up and running. And an editor for designing ground objects would be great to include, though simply designing a user interface for such a program is a subject worthy of its own book! My wish list also includes polygon smoothing, using either Gouraud or Phong shading (or modified versions thereof), a subject I suspect there'll be great enthusiasm for among the crowd in this forum. Gradient-fill horizons would also be fun to play around with. Although I discuss horizons at some length in FOF, adding the gradient would add an interesting and exciting new level of complexity to an already complicated task. Bitmaps are another topic that can be covered at _incredible_ length! In fact, there could be a completely separate book in that one (though I've got dibs on writing it!). STRIKE COMMANDER looks like it's about to introduce a whole battery of new techniques, many of them having to do with rotated bitmaps. Most importantly, there's an entire new genre of bitmapped dungeon games now attaining unbelievable popularity -- ULTIMA UNDERWORLD, WOLFENSTEIN 3D plus several upcoming shareware and commercial games that are going to blow people's socks off! The excitement over these games has been quite palpable among the game designers in this section. I'd love to do a _parallel_ sequel to FOF concerning these things. (Perhaps it could be called Dungeons of Dread?) This would allow me to discuss the various kinds of texture mapping -- vertical post, three-dimensional -- and their application to interior maze exploration games. And I've got an idea for a _great_ chapter on monster animations! <g> As for the FOF sequel, there could be an entire _section_ covering the airplanes themselves -- external views of planes, combat systems, multiple airplanes, aerial combat sequences. And perhaps, instead of modelling a simple propeller driven plane as in FOF, the sequel could concentrate on jets. A HUD could be added to the cockpit view, with the ability to lock onto targets, follow them on radar, launch missiles, etc. Other possible topics: Mode X animation, SVGA animation, Truecolor (24-bit) animation, VESA programming, use of XMS and EMS to store data, and (if Borland updates their compiler to handle it) full 386 protected mode programming. Yeesh, what am I getting myself into?! <g> --Chris ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 333188 To: John Dlugosz [ViewPoint] 70007,4657 (X) Date: 13-Apr-93 22:14:17 The key point about the raycasting is that the scenery is strictly two-dimensional; only height values for terrain "points" (the grid elements) are stored. So when you look across the terrain at an angle, what you see is the differences in heights between terrain points, as vertical lines. As a ray crosses a straight-line sequence of these terrain points, a vertical line is drawn each time in the current screen column to represent the difference in height (the "rise," if you will) between each terrain point and the one beyond it. Perhaps a different color could be used for the top pixel of each "rise" to differentiate it from the side of the rise, to give a light-sourced effect. This is hard to explain without a picture. Taking a good look at the COMANCHE screen helps. Have you played it? There's a demo over in GAMAPUB LIB 16 if you haven't. Search on the keywords NOVALOGIC or COMANCHE. Yes, it would look pretty nifty in 320x200x32K, but not enough people have it yet to make it viable for a game. Heck, the graphics board I've got in my machine currently can do 320x200x16M, which would look _really_ neat! (And would be _really_ slow! <g>) --Chris ........................................................................... Fm: John Dlugosz [ViewPoint] 70007,4657 # 333277 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 14-Apr-93 00:25:34 <<So when you look across the terrain at an angle, what you see is the differences in heights between terrain points, as vertical lines.>> So what _color_ is it? That is, what's the surface normal? Looking at a nest of vertical poles will give me a solid blank wall of uniform color. <<slow>> manipulating 16-bit pixels is _faster_ than 8-bit pixels if done one at a time. I would buffer strips and write a whole pixarray at once, so it does translate to a speed difference. But I don't think the extra writes are significant compared to the other processing. I'm thinking of a demo and example, not a full game! If it makes you dizzy, so much the better <g>. I kind of like my tent-pole ideas. Wonder how fast I can get it? How about higer res than 320x200? Even if not good for realtime animation, it means I can redislay the surface I'm viewing from any angle in a small fraction of the time it takes with the method used in SURFACE/SHOW that I think I sent you. For each point in the field, I need a height value and 6 colors. Be lavish and figure 13 bytes each. That means 400K would be good for 31K points, or 177 points square. The mountain in my SURFACE program is 128 square. Sounds doable. --John ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 333456 To: John Dlugosz [ViewPoint] 70007,4657 (X) Date: 14-Apr-93 10:06:08 I'll have to go back and reinstall the COMANCHE demo to think about the color business. I assume that the colors are determined in advance, since the terrain never moves and therefore never has to be re-lightsourced (unless the sun is assumed to be moving through the sky, which isn't really necessary). Thus, shadow and light effects could be precalculated and stored in the array, if there's room. Some "vertical poles" will be dark, some light, most somewhere in between. A hell of a lot of work to precalculate and store, yes, but the effect should be worth it. Of course, I already see the flaw in this: what if a pole is half in light, half in shadow? How do you store that? Like I said, I'd better go reinstall COMANCHE (as soon as my taxes are done <g>). Try to hold your res down to 640x480, because that's all my current monitor can handle. BTW, I was unable to run that fractal mountain demo you sent me, because it wants to run at a higher res. Is there a command line switch I can use to get it down to 640x480? (If all you guys will keep buying copies of FLIGHTS OF FANTASY, I promise to invest a chunk of the royalties in an SVGA monitor! <g>) --Chris ........................................................................... Fm: Mark Betz/Ass't SysOp 76605,2346 # 333013 To: John Dlugosz [ViewPoint] 70007,4657 (X) Date: 13-Apr-93 19:38:20 I've been thinking about raycasting, too. The basic cut of it that I understand is that you cast a ray from the POV to each pixel of the 320 vertical columns (or whatever number is visible), stopping at the first location in the x-z plane that has a feature in position to occult the ray. You then draw a pixel at that point in the appropriate color. Height data is a 2d array of y offsets. I imagine some sort of highly optimized 3D Bresenhams could be used to cast the ray. --Mark ........................................................................... Fm: John Dlugosz [ViewPoint] 70007,4657 # 333173 To: Mark Betz/Ass't SysOp 76605,2346 (X) Date: 13-Apr-93 21:58:58 No, you will not cast from a single POINT of view through each pixel in the screen. Rather, you will make all the rays paralell, not meeting at a point, passing through each pixel. Anyway, imagine a bunch of telephone-pole-like objects of various lengths. The top surface is the x-z point and the pole is elevating it in y. Your ray hits the side of the pole, not the top. What color to make it? It just doesn't make sence. Instead, stretch a rubber sheet over the poles and nail it down in the middle of each one. this causes a bunch of flat triangles to appear. Each one of these can be colored ahead of time. _this_ is what I want to intersect with. So, back to the first pole image. There are 6 triangles meeting at the top of the pole. Based on which pole I hit and the direction I was coming from, I identify the triangle. Hmm, since the direction is always the same, 6 colors per pole is enough, and I figure out which one ahead of time and use it for all 64,000 casts. That's it!! Thanks, I understand it much better now. --John ........................................................................... Fm: shmuel cohen 70431,1617 # 332968 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 13-Apr-93 18:34:24 Good job! I'll go back through the joystick stuff - but probably not tonight - I just spent the day on Uncle Sam's stuff - and boy did I take it up the ol' !@#$@. Anyway, after I recover from my comatose state I'll dig into the joystick stuff. BTW, one last optimization on the Pcx::Display routine - add the screen.h header file to the pcxclass.h and then replace the Pcx::Display() function with this: void Pcx::Display() { blitscreen ( image ); } By using Mark's blitscreen, we get a further improvement of 10% on my machine, probably more on others. This process might also make an interesting sidebar in a future addition - especially if you have another section on optimizations - going from you For loop to memove to Mark's asm routine. ........................................................................... Fm: Mark Phillips 73167,3216 # 332662 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 13-Apr-93 10:05:26 Chris, I am slowly working my way through FoF. First, Chapter 2 is the clearest explanation of 3d math I've ever seen. Perfection! I found some typo's though. In ch. 3, at the top of pg. 73 you say the function number of a video BIOS call goes in AL, and the code fragment says the same thing. Listing 3-1 has it correct, with the function number in AH. Pg. 75 has a C code fragment with 13h in it, shouldn't it be 0x13? The text at the top of pg. 82 has the same problem as pg. 73, AH and AL are reversed. In listing 3-3 the comment doesn't match the code, the code is hardwired for all 256 palettes while the comment indicates it should pass parms for FIRSTREG and NUMREGS. Finally, (g) the Table 5-1 says the joystick read function is 16h, should be 15h. All minor problems. I'm a real beginner at C (I'm trying to convert FoF to PowerBasic), so any code typos were certainly missed by me. Thanks again for the great book! mjp ........................................................................... Fm: David K. Morton 70750,1105 # 333069 To: 76711,301 (X) Date: 13-Apr-93 20:15:07 Chris: I bought the book on Flights of Fantasy last weekend and decided to try to compile it on my machine. The Make facility stoped at the file drawpc.cpp. Is this in the book someplace or on the disk? I could not find it in or on either. Could this be in the library. Thanks in advance. Dave Morton 70750,1105. ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 333145 To: David K. Morton 70750,1105 (X) Date: 13-Apr-93 21:28:50 Looks like I renamed a file without updating the makefile. (I was using the Borland PRJ file myself.) Best way to fix this is to edit the makefile so that DRAWPC.CPP will read DRAWPOLY.CPP instead. If that doesn't work, get back to me right away, and I can probably suggest some alternative fixes. Thanks for catching that! Yet another change for the next printing! --Chris ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 333481 To: All Date: 14-Apr-93 11:12:39 For those of you who have purchased my book FLIGHTS OF FANTASY, I just wanted to mention that a bug has been reported in the program OPTDEMO.EXE, which illustrates optimization concepts discussed in Chapter Nine. This is the program that rotates shaded cubes and pyramids. Although the rotation works just fine, the scaling functions (operated by the + and - keys) do not work. If you use them, the cube swells beyond the proportions of the viewport, trashing memory and locking up the machine. (Cute, right? <g>) This is a version control problem: The version that was _supposed_ to go into the book should have had the scaling functions disabled, since clipping code had not yet been introduced in the book at this point and could not be used to prevent memory from being clobbered. The solution? Don't use the scaling controls! <g> I'll post another version shortly with these controls disabled. For those who have not yet purchased the book, don't worry. This problem doesn't affect the flight simulator -- or any of the other programs in the book. But it creates quite a spectacular visual effect right before it crashes your machine! ;-) Sorry about that one, folks! ........................................................................... Fm: Hans Peter Rushworth 100031,473 # 337130 To: Mark Betz/Ass't SysOp 76605,2346 (X) Date: 18-Apr-93 21:09:25 >> I'm struck by the difference between the crystal clear bowl in which most flight sims operate, and the film footage I've seen. There's a atmospheric hazy quality to most of it that the sims haven't reproduced. That's true, conversely, on clear, bright, sunny days (or when you're above the clouds) there is an intensity to the light that you cannot reproduce on film, or on a display screen (unless you have a projector and you look into the lenses!). Under these circumstances sunglasses are mandatory. It is virtually impossible to see another aircraft if it is flying "out of the sun". In fact it is most often VERY hard to see the other aircraft when it is below you against the ground. Let alone flying through cloud. It is also surprisingly difficult to pickout things like runways that are designed to be easily seen. It's no accident that excellent vision is a mandatory requirement for pilots, especially in the military. Haze is a factor, but the sun, ground complexity and clouds are perhaps more significant, in my (limited) experience. I'm not sure I would agree that speckle is an accurate model for haze or fog. Distant objects "become grey" and/or "lose spatial resolution", but they don't get "noisy" (like untuned TV), or do they? The "mirage" shimmering effect on hot days occurs only if you are close the ground (I think). Of course I don't mean to suggest the dithering or similar methods are not appropriate in solving problems in computer graphics. Peter. ........................................................................... Fm: rod lentz 71163,57 # 337952 To: John Dlugosz [ViewPoint] 70007,4657 (X) Date: 20-Apr-93 01:16:44 >> integer sqrt() The integer sqrt() method I'm current using is based upon Newton's method of successive aproximations; in asm, it's the fastest I've tested yet for the 386+ cpu's. I believe that two versions from me, and several others from other contributors went into the "wolf3d.thd" that was just u/l'ed. If it's not in there & you want specifics, let me know & I'll send it over. >> and distances via table trig My most frequent use of table trig so far is for calculating 2d distances without sqrt()s. This is using a table of pre-calc'ed cos (atan ())'s. The elements are currently stored as rationals (numer, denom), which can also be treated as vectors. I'll probably change these over to fixed point soon. I've just started adding a few more similar trig tables for some special uses. I've got tables all over the place ! BTW, tables are also great for _quickly_ doing simple image processing on "packed rgb pels" (mapping an rgb cube in 256 color mode). Mixing, adding, &c.; although the memory overhead is quickly rising <g>. ........................................................................... Fm: Hans Peter Rushworth 100031,473 # 337471 To: John Dlugosz [ViewPoint] 70007,4657 (X) Date: 19-Apr-93 13:03:58 John, >> I sent stuff that uses 256 color, and a mode13h driver. This records my experiments. Yes, got it (twice <g>), thanks. I did some tests using your ideas in my own shading routines. It's very sucessful in removing the ring artifact where the difference between shades is very small (ie if you have a lot of shades), but with larger intensity differences it is less good (you then end up with wider, albeit unfocussed, rings). It seems that the diffusion depth between regions needs to be a function of the difference between available shades for a given surface. I'll play with it a little more and see if I can get better results for this situation. ........................................................................... Fm: Hans Peter Rushworth 100031,473 # 337526 To: Hans Peter Rushworth 100031,473 (X) Date: 19-Apr-93 15:40:02 Ok, simply adding a small fixed amount of noise cures this problem. The amplitude of noise needs to be reduced for the surfaces that are rendered with a colour that has more palette shades allocated to it to prevent those surfaces looking noisy. In essence: pixel_intensity += (distinct_shades > 16) ? rand() & 3 : rand() & 7; The results are surprisingly good, and let you get away with fewer shades (and hence giving you more free colours in your colour map). Mark: If you want a SHADE update which has this dither option, just ask. Peter. ........................................................................... Fm: rod lentz 71163,57 # 337538 To: Hans Peter Rushworth 100031,473 (X) Date: 19-Apr-93 15:52:48 John - I played with the sample; looks good ! Still looks a little slow for real-time, though. In my experience, if you have enough [spatial] resolution, adding noise of +-1 target level does a good job of minimizing rings & similar artifacts. +-0.5 probably gives a more technicly accurate dither, but subjectively I find less preferable. Also, if you have enough spatial resolution, dithering _all_ shades, even "pure" ones in the palette, looks good. It gives a slightly pointilistic effect, but one I like. If high enough res, spatial integration does a great job with this effect. Let me dig around; if you want, I'll send out a copy of my "noise diffusion" dithering. ........................................................................... Fm: Mark Betz/Ass't SysOp 76605,2346 # 337927 To: Mitchell Waite 75146,3515 (X) Date: 20-Apr-93 00:41:43 I believe that is the problem, Mitch, yes. FoF was developed on machines with FPU's, and while it was tested on machines without them, it was not tested to a great enough extent that I could make a representation. I was afraid that the emulation would prove to be very slow, and sadly that fear has manifested itself in reality. The lesson is to implement your own fixed-point math and stay away from the emulator. --Mark ........................................................................... Fm: Mitchell Waite 75146,3515 # 337888 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 19-Apr-93 23:43:37 How about this for scenery direction algorithms. Look at Gary Yost's 3D Studio IPAS routines, particularly Silicon Gardens' plants, trees, and other nature schrubs. They make plants and plants and terrain have a lot in common. Another idea is to find some equations to simiulate wrinkles. Ding! I think POV Ray has a wrinkles function. I know it can generate a texture that goes inside an object. Perhaps one could use POV Ray to generate a large wrinkled bit map 2D image. Then a program could be written to process the color info to represent height. (Details could be drawn with POV Ray into the bit map in any size if you wanted zooming.) Then figure out how to get the viewers POV on the screen at 14 fps :) ........................................................................... Fm: rod lentz 71163,57 # 337978 To: Mark Betz/Ass't SysOp 76605,2346 (X) Date: 20-Apr-93 01:44:46 It's a rare occasion I ever use the emulator. For years, I've been jumping through hoops (as most others) to use int's, rationals and fixed points. Now, it's so ingrained that I rarely use floats, even if the app isn't time critical & I know it will only be run on my (486dx) machine. Also, I was once writing a tsr in msc, and discovered that my one use of floating point (addition only) caused the entire emulator to be included. At about 11k, it was an awful lot of overkill for that little use, and I switched to fixedp. - Rod ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 338169 To: Mitchell Waite 75146,3515 (X) Date: 20-Apr-93 11:31:53 Wrinkles would be yet another fractal feature (and probably as slow as the rest <g>). Does POV ray generate the wrinkles or is it working from a pre-existing bitmap? Sounds like it would be easier to get FRACTINT to generate something like that and work backwards from it. Best of all, I'll just look at the source code to both of'em and see what I can steal, er, learn from. ;-) --Chris ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 347021 To: Ian Christie 70534,403 Date: 03-May-93 14:16:52 There are some problems with three of the programs. WAITE.EXE _does_ cause a memory allocation error, OPTDEMO will crash if you use the scaling keys (+ and -), and FOF.EXE locks up on a few machines, all fast 486s. I haven't heard of any problems with POLYDEMO. In the first two cases, the problem is with clipping. Since polygon clipping hasn't been introduced at that point in the book, it's not used in those programs, and it's needed. <g> Unfortunately, I didn't trap out all cases where polygons could run off the virtual screen and trash memory. As for the FOF.EXE lock-up -- we aren't sure yet what causes it. Two possible clues: it only seems to happen on fast 486s without joysticks and/or gameports; and some people have reported that the problem clears up if they install the program a second time. Does your machine have a gameport? And have you tried reinstalling? If you do reinstall, I'd recommend clearing up a little extra disk space, in case it's some kind of out-of-memory error. How much free space do you have on that drive, BTW? Any insights you may have as to what's causing the FOF.EXE lock-up would be appreciated, since we haven't been able to duplicate it. When we do, we're going to make a fixed version available. Thanks for the report! --Chris ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 353865 To: Jeff Ross 71561,3161 Date: 13-May-93 05:14:42 Jeff: You're correct about everything except the bitmap compression. The cockpit bitmap is compressed only once, when it's initially loaded into memory, and is stored in a buffer. It remains compressed (without being recompressed) for as long as the program continues running. For each individual frame of the animation, a decompressed version of the bitmap is drawn over top of the 3D view, with the view showing through the transparent portions of the cockpit. (The decompression is performed by the Ctransput() function, described in Chapter Fifteen.) The reason that the cockpit is maintained in compressed form is that it can be moved to the video display much faster that way, without transparency checking (and transparent pixels can simply be skipped altogether). In an earlier version of the code, we maintained the bitmap in uncompressed form and it ran _unbelievably_ slow! Compressing the cockpit bitmap more than quadrupled our frame rate, if I recall correctly. --Chris ........................................................................... Fm: Rasputin 71005,2524 # 358678 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 19-May-93 23:52:44 Chris, after several people in this forum recommending your book to me (FOF), I finally got it (It was a birthday present from my mom!). anyways, I was pondering the Idea of the Z buffer, and came up with a theoretical solution to make it faster, and possibly faster than the painter's algorythm (sp?) anyways, it goes like this ... Instead of storing the Z for each point, store the Z for a run of points... presumably in the polygon drawing routine... and don't actually plot those points at that time, store them in an array of line runs... when a lower Z comes along, you could perform surgery on the array as necessary to reflect the changes(leaving the pixels that weren't covered, and modifying longer runs that were covered only in the middle. then when it actually came time to draw the runs, you could compare them with the array of runs that you drew for the previous screen, tand avoid redrawing long runs of pixels, thereby bypassing the need to erase the old screen, or draw large areas of the screen that didn't change... I know that my explanation of the theory I have formulated is kind of sketchy... do you get where I'm coming from? any and all responces welcome. Dan Kelly. ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 359234 To: Rasputin 71005,2524 Date: 21-May-93 00:53:08 Dan: Interesting idea, but I'm having some trouble visualizing how the Z runs would be stored. I assume they'd need to be horizontal runs, since that would optimize the actual drawing of the pixels when the time came to do so. But that means one end of the run could have a different Z value from the other, since there's no guarantee that the run will be parallel to the display plane. So the structure would need to be designed to store at least two Z values for each run in a way that would allow fast comparisons between overlapping runs. The main problem might be quick identification of overlapping runs -- i.e. how do you rapidly determine which old run to compare a new run against? Perhaps with a binary search of some kind? If you could find a way to organize the structure efficiently (as some kind of tree?), it might be more accurate than an unaugmented depth sort and faster than a complete Z buffer. Could be worth thinking about in more detail. Come to think of it, there's a hidden surface removal technique called the scan-line method that I ran across while writing FLIGHTS OF FANTASY that's similar to what you're describing (or at least to the way I'm visualizing it). I haven't really studied it and can't pretend that I understand the details, but if you've got access to a copy of Hearn and Baker's COMPUTER GRAPHICS (my favorite reference when I was writing FOF), it's discussed on pages 264-265. It involves performing a separate sort of polygon edges for each scan line in the viewport. My superficial impression is that it would be too slow for realtime animation on current generation processors, but might be similar to the way your Z run method would work in practice and could be superior to the Z buffer in some circumstances. You might want to check it out to see if it gives you some ideas. --Chris ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 363026 To: All Date: 26-May-93 04:56:35 Those of you have encountered the mysterious lock-up problem with the FOF.EXE flight simulator that comes with my book FLIGHTS OF FANTASY (where the sim locks up immediately after the opening title screen) will be happy to know that Mark Betz and I located the source of the problem last night. I'll be uploading a fix as soon as Mitch Waite and I decide on what form the fix should take. For now, you can fix the problem yourself if you have the BC++ compiler (or TC++ and TASM). In module AIRCRAFT.CPP, change line 544 from loopTime /= 1000; to if (!(loopTime /= 1000)) loopTime = 1; and recompile FOF.EXE. This _should_ fix the problem. (It avoids a Divide by Zero error later in the code that apparently only occurs on fast machines without joysticks or sound boards to slow down the simulator's initial loop timing calculations.) If it _doesn't_ fix it, let me know right away. Thanks! ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 365830 To: Ian Christie 70534,403 Date: 30-May-93 21:56:29 The fix for the FLIGHTS OF FANTASY lock-up bug that occurs on some fast machines is to change line 544 of AIRCRAFT.CPP from loopTime /= 1000; to if (!(loopTime /= 1000)) loopTime = 1; and recompile FOF.EXE. Let me know if that works for you. --Chris ........................................................................... Fm: Paul Whittemore 72007,3305 # 367865 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 02-Jun-93 19:45:16 Just found my first FOF bug... Try pulling back until you're inverted and look out either side. As you cross the 90 degree mark you'll see a weird 'flash'. But even if you miss this, while flying inverted, pull back. This should send you toward the ground. It does, but in the side views, the pitch is reversed so it *looks* like you're climbing inverted. Eventually, you'll crash, but the view indicates climbing. Got some more FOF reading to do or I'd find the offending line right away. (Don't wanna get dirty ... yet.) Paul ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 368104 To: Paul Whittemore 72007,3305 (X) Date: 03-Jun-93 03:42:38 I'm familiar with the "flash" bug. I chased it for a while but never caught it. Finally, I just left it in. Ultimately, the problem has to be in the draw_horizon() function, though it might be triggered in turn by something earlier in the code. That's where to start looking, though. That function, which draws the sky and ground background colors, was the second most difficult part of the code to write. (Hidden surface removal was the hardest.) Took at least two weeks to get that one function working properly. And still, under certain conditions, the sky and ground magically reverse. (That's what causes the flash.) It only happens for a single frame at a very few orientations and I never was able to figure out why. If you do, be sure and let me know. I hadn't noticed that problem with the side views. I remember how crazy Mark and I went figuring how to calculate the side views, so obviously we missed something. I'll try that and take a look. Once again, if you find the cause, let me know! --Chris ........................................................................... Fm: Hans Peter Rushworth 100031,473 # 368718 To: Mark Betz/Ass't SysOp 76605,2346 (X) Date: 04-Jun-93 00:42:42 Mark, >> Does it handle the view orientation correctly from all angles? Yes, It works right off the rotation transform matrix, so whatever combination of heading/pitch/bank/yaw etc is automatically catered for. It still has the obligatory 16-way switch, of course. <g> I'll see if it's in a state to post, if not I will email it... Peter. ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 368686 To: Hans Peter Rushworth 100031,473 (X) Date: 03-Jun-93 23:55:24 Actually, I would kinda like to see that horizon routine, if you'd still like to send it on. It could be useful to see how you approached the problem, assuming you've made some changes from last summer's version. --Chris ........................................................................... Fm: Hans Peter Rushworth 100031,473 # 368908 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 04-Jun-93 11:11:15 Chris, I'll email you the full version, the trick is how to calculate window intercepts and decide upness. The following is a brief explanation of how it works, that I wrote at the time to our project supervisor. You can tell from this that I was extremely pleased with myself. <g> ____________ (28-November): Using the equation for the horizon plane and plugging the values for the window edge vectors into it will give a unique solution for the window intercepts. The equation of the horizon plane comes directly from the plane normal, which is the 3rd column in the CTM. For Example, after some re-arrangement, the equation that gives the Y value of the right window edge intercept (when valid) is simply -((a + c) * height of window)/b) where [a] is the 3rd column of the CTM. [b] [c] (if b is zero, it means that the horizon is outside the window, you test for this first obviously). The other intercepts are similar. Whats more, the question of "up" is solved by examining the sign of just one co-efficient in the matrix. (actually there is one case where you need to distinguish left from right, which just uses a different co-efficient of the matrix). When I looked at this first I thought it was so simple it could NEVER work. Surprise surprise. I can now calculate the intercepts of the horizon with the window edges for **_ANY_** orientation DIRECT from the CTM with ZOOM and SIZE/SHAPE taken into account In FOUR LINES of code. No trigonometry, mammoth overloaded behind your back matrix operations either. I am amazed. To think that I slaved for hours over trig methods and couldn't get it to work before, when this method is so direct and simple. So anyway, the horizon works now. __________ Peter. ........................................................................... Fm: Jeff Ross 71561,3161 # 368063 To: Chris Lampton 76711,301 (X) Date: 03-Jun-93 01:14:34 Chris, Help. I've tried several times to change the NUMBER_OF_DEGREES in the SIN/COS tables but have had no luck. Generated 360 and 300 degree tables using makesine.cpp and then incorporated them into the project. All rotations are very jerky and unusable. Thought the problem might have been in the mapangles routine in DrawHorizon, but, that didn't help. For instance; with either of these new tables and rotating around the y axis (yaw) it will move for roughly 2-3 degrees and then jump back, then if I keep pressing the key it will suddenly jump a whole bunch of degrees in that direction. Do you think it may be a problem in actually generating the tables in Makesine.cpp? It seems pretty straight forward. Perhaps in the Fixed-point usage? I'm new to this 'Fixed-point' stuff so I could be missing something here. I realize it's probably something very minor/obvious but I cant' seem to see it. I figure you had a reason for 256 degrees and maybe you could steer me in the right direction. As always, thanks Jeff ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 368088 To: Jeff Ross 71561,3161 (X) Date: 03-Jun-93 02:24:43 I was afraid of that. I never tried changing the number of degrees myself, so I really don't know if it could be done that easily or not. As I said in an earlier note, I may have assumed the 256 degree system somewhere in the code. I'll take a look through it and see if I can locate the assumption. It's probably in the view system somewhere, since Mark uses a different rotation system altogether in the flight model. Might just be a matter of making simple changes to the code. I'll get back to you on it. --Chris ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 368101 To: Jeff Ross 71561,3161 (X) Date: 03-Jun-93 03:42:23 Okay, I think I may have found the problem. It's not in the FOF source code, but in MAKESINE.CPP, in the lines that write the SIN and COS macro definitions to the header file. These macros return a value from the sine and cosine arrays declared in FIX.CPP, first ANDing the array index with the NUMBER_OF_DEGREES minus one. (This is a fast way of getting the index modulo the number of degrees, as long as the number of degrees is a power of two.) I've hardcoded a 255 here. Rewrite this so that it will AND the index with the value of NUMBER_OF_DEGREES minus one. And be sure the new number of degrees that you choose is also a power of two (i.e. 512, 1024, 2048, etc.). If this is confusing, let me know, and I'll send you specific code. --Chris ........................................................................... Fm: Jeff Ross 71561,3161 # 368569 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 03-Jun-93 21:33:13 Chris, Okay! Great! I thought it might have been in Makesine.cpp but it all looked fairly straight forward to me. I guess I didn't look very hard since it was a short routine. So, if I get you: Change ... const NUMBER_OF_DEGREES = 1024 // for example 1024 degrees Change ...cos_table[ABS(X)&1023]... ...sin_table[ABS(X)&1023]... I'll try this out probably friday and let you know. Also, I'm basically, so far, using the book as defined in chapt 15, interfacing the View system. No code for flight model etc since I'm going in a different direction here. Have noticed that when I translate my position beyond a certain point I seem to 'wrap' back around in the world database. Doing a straight increment of the curview.copx/y/z values until I get my flight model hacked out. Haven't had a chance to dig into this yet but before I do, is that the way it was intended? The version I'm running uses your code as is, no mods at all, and the world database that came with it "FOF2.WLD". Didn't see any mention of this in the text. Again, many, many thanks. I'll get back to ya, Jeff PS: Must thank you again for writing the book! As I've said before I've been trying to write a flight sim since I created my first "hello world!" program n QBasic. You've saved me probably 6 months of work. My only problem now is that a little information is becoming dangerous. I find I spend so much time coming up with algorithms and ideas for features (since I now have an "engine" for showing them) that I have a tuff time sitting down and putting the whole thing toghther! This is fasinating to me. ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 369081 To: Jeff Ross 71561,3161 Date: 04-Jun-93 17:16:57 Yes, that's exactly what you need to do to change the number of degrees. (I see from your next note that you got it working, but I was too tired yesterday to respond to most of my messages so I'm responding to the earlier one instead. <g>) The wraparound is discussed in the Appendix and in the README file on the disk. It results from the fixed point routines, which only allow 14 bits precision to the left of the decimal point. Hence, there's an automatic coordinate wrap at position 16384 on any axis. If you want to rewrite the fixed point as a function or overloaded operator using 386 registers, you can improve this considerably. There would still be limits. A commercial sim would load a new database before wrap occurs, but FOF.EXE isn't that sophisticated. --Chris ........................................................................... Fm: Paul Whittemore 72007,3305 # 369269 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 04-Jun-93 22:24:24 Although I said I was going to finish the book first, I spent some time last night looking at the horizon problem with inverted side views. (Since I haven't gotten to the corresponding chapter of the manual yet, you can take the following with a hunk o' salt.) I don't think the problem is in the display_horizon method. I think it's in the caller (display). In fact, it may be a more general problem related to the inverted sign of Y coordinates. And I think the horizon flash is related to this problem, and may even be the same one... (Just a feeling.) The view is fine, except that the slope of the horizon needs to be negated in the case of an inverted side view. I tried forcing this, but realized the *objects* were also moving in the wrong Y direction. (With the correct horizon, mountains would fly up into the air at the -angle that the ground was moving away. Since the problem is not limited to the horizon, it's not *really* in draw_horizon. I don't know about the world/view system yet to take it any further, yet. And I wanna finish the book first, but I'll keep you posted... Paul ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 369353 To: Paul Whittemore 72007,3305 (X) Date: 05-Jun-93 00:33:55 No, I wouldn't expect to find the side view problem in draw_horizon() either, though I'm pretty sure that's the place to look for the flash problem. I'd be surprised if the two problems were related, though I could be wrong. (It's been a while since I wrote this stuff, after all.) The best place to look for the side view problem is in the ViewShift() function. (See pages 524-525 in the book.) This is where we calculate the change in view angle for views other than straight ahead on the viewer's local z axis. Mark and I passed this function back and forth between ourselves a couple of times before we got it to work properly -- and we may still have missed some special cases. Check it out and see if you can see what we might have missed. It always helps to have fresh eyes look at the code. The case statement on page 525 cycles through the right, back and left views -- or is it the other way around? Hey, Mark! ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 372824 To: Paul Y. Chong 72762,2775 Date: 10-Jun-93 01:17:04 Paul: The FOF lock-up problem is triggered by a divide-by-zero error in module AIRCRAFT.CPP. It only occurs on fast machines, usually without a sound board and/or joystick to slow things down, which is why we missed it when putting the program together. If you've got the BC++ compiler you can fix it with a simple change to the code. Change line 544 of AIRCRAFT.CPP from loopTime /= 1000; to if (!(loopTime/=1000)) loopTime = 1; Let me know if that works. Good luck! --Chris ........................................................................... Fm: Paul Whittemore 72007,3305 # 376168 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 14-Jun-93 18:57:59 I noticed some minor improvements: like the blitting was done 32-bits at a time (STOSD rather than STOSW) and I used incremental offsets in one loop (from Ch. 9) rather than multiplication. (Things like that.) BTW: I've more or less decided to do a *new* flight sim since I don't want to have to worry about legalities and other people's priorities, but one heck of a lot of the effort could be applied to FOF as well. A complete 386 assembler fixed point library, network/modem support, external views, enemy planes, weapons, other moving objects (e.g. ground vehicles), variable altitude ground level, textured ground and my potential plan for bitmap-wrapped objects. It could all be added to FOF as it becomes available without compromising my project (if it ever materializes). ........................................................................... Fm: Paul Whittemore 72007,3305 # 378921 To: LYNN L. HOWARD 71054,3050 Date: 18-Jun-93 20:27:43 I tried recompiling the FOF source with -3 and my times dropped from 44 ms/f to between 36 and 39 ms/f. I've written the necessary 386 32-bit fixed point routines, except for division. (The book says only addition, subtraction and multiplication are necessary, but the source says otherwise.) There are several initialization-time conversion functions required too, (and their also done), but I don't think they're needed per frame. I'm going to take a stab at complete replacement for all the float/double and 16-bit fixed point math as soon as I get a chance. I'll keep everyone informed of any performance gains I can get. Thanx, Paul ........................................................................... Fm: Andrew Amess 100141,1567 # 378691 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 18-Jun-93 14:19:12 Hi, interested in your comments about buffer moves to VGA. I am currently writing games for the 386 and above which have 9 and more levels of parallax. I can upload some early demos, which look rather good. Anyway, about block moves, I have an idea and tried it out but didn't profile it, maybe it will ring some bells. I interleaved the move bytes to VGA code with move 0's to the system ram video buffer wondering if the processor would do the blit/clear loop quicker. A friend said yes it should because whilst the data is going down the bus you can be writing to system RAM. Also, where can I find chit chat on optimising code as I need every cycle I can get my hands on at the minute. TIA. Chris Nurse (Using Andrew Amess account). ........................................................................... Fm: Andrew Amess 100141,1567 # 379165 To: Paul Whittemore 72007,3305 (X) Date: 19-Jun-93 09:19:54 With the fixed point matrix multiplier, which I have also done in assembler:- To divide matrices do I just change my IMUL to a DIV etc... I have a rather nice assembler version which uses a macro and have unrolled the whole multiplication so you can get something in excess of 4500 complete operations per second; Is that good? I have nothing to compare against as I am not heavily into FOF code but the book has proved to be a gold mine since the day I got it! ........................................................................... Fm: Paul Whittemore 72007,3305 # 380186 To: Andrew Amess 100141,1567 Date: 20-Jun-93 20:53:04 > With the fixed point matrix multiplier, which I have also done in > assembler:- To divide matrices do I just change my IMUL to a DIV etc... With both the multiplication and division, it's not that simple if you don't want to lose much accuracy. With fixed point 32-bit division, the simple division results in a complete loss of the fractional part (37/4= 9.000). I'm planning on shifting the numerator left by as many places as there are high zero bits (up to the number of bits to the right of the fixed point). Then shift the denominator right for the difference. This should maximize precision without changing from a single division. There are other methods I'm looking at, too. For multiplication, I'm looking at detecting overflow and returning 0x7FFFFFFF (my 32-bit fixed point numbers are signed) which should be good enough for 'fuzzy' accuracy like flight simulators. I want to prevent wrap while still allowing the large numbers to be multiplied together. I haven't had enough time yet to really look at it, but when I finish off the routines, I'll post them for general use. They're BC++ and TASM and assume a 386+ for the 32-bit accuracy. Regarding your routines: it doesn't sound like 32-bit accuracy if you can implement them in a macro. I don't have any idea about the performance yet, so I can't say whether you numbers are good or not... Paul ........................................................................... Fm: Eric Klein 72302,2731 # 381056 To: Mark Betz 76605,2346 (X) Date: 21-Jun-93 21:45:31 The FOF program from "Flight of Fantasy" book, hangs afters the initial credit. I am using a local bus DX2-66 with "Diamond Stealth 24" local bus video card. Running FOF with "D"(debug) parameter gives a message "floating point error:Domain" and then hangs. Debuging through FOF it seems to crash in the image routines. Any ideas of how to solve this problem? Also where could I find the lastest source for FOF? FOF runs fine in a compaq DX2-66 with Q-Vision video. ........................................................................... Fm: Chris Lampton [GAMPUB] 76711,301 # 381152 To: Eric Klein 72302,2731 (X) Date: 21-Jun-93 23:29:48 Eric: The FOF simulator sometimes locks up on fast 486s, especially if they lack a SoundBlaster and/or joystick to slow down the code. If you've got BC++, change line 544 in module AIRCRAFT.CPP from: loopTime /= 1000; to: if (!(loopTime /=1000)) loopTime = 1; and recompile. That should fix the problem. I plan to upload the fixed EXE file to LIB 11 here within the next couple of days. --Chris ........................................................................... Fm: Mark Betz/Ass't SysOp 76605,2346 # 381476 To: Eric Klein 72302,2731 (X) Date: 22-Jun-93 12:33:18 Hi, Eric. We had a problem with the program on very fast machines, often those with neither a sound card or a joystick, which caused it to lock up right after the opening screen with a FP domain error (divide by zero). Essentially what is happening is that on these machines it takes less than 1 millisecond to get from the point in initialization where the timer is started to the point in the flight model where it is read for the first time. Since the elapsed time in microseconds is divided by 1000 to obtain milliseconds, this situation results in an elapsed time in milliseconds of 0. This is then used as a divisor in parts of the flight model, causing the error. The author is getting ready to make the new version of the executable available here in Game Design, but in the meantime the fix simply requires making sure that loopTime cannot have a value of 0 on the first pass. --Mark ........................................................................... Fm: Paul Whittemore 72007,3305 # 382526 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 23-Jun-93 19:36:54 > I plan to upload the fixed EXE file to LIB 11 here within the next couple > of days. You may want to consider uploading one recompiled with -3 also, since the performance improvements are reasonable... Just a thought. Paul P.S. Still working on a complete replacement with 386-specific 32-bit fixed point, but I have a (work) deadline of Friday and I move on Tuesday so I've had to postpone it temporarily while I work like a dog... ........................................................................... Fm: Eric Klein 72302,2731 # 382399 To: Chris Lampton [GAMPUB] 76711,301 (X) Date: 23-Jun-93 16:12:00 I recompile with your change and it works now. Thanks for your quick response. Eric ...........................................................................